Hi,

 

We have some weird behavior regarding the execution of our temporal set job and we cannot determine if there is a bug or if something is wrong with our design.

 

1. The FIM_TemporalEventsJob runs at 1:00 am every night.
2. There are warning in the      Event Viewer (Windows Logs/Application) for the source Microsoft.ResourceManagement.ServiceHealthSource regarding some groups and      sets.
3. Here is a sample message for      a group, stating that an attempt to remove a member has been done (event id 34).

"The Forefront Identity Manager Service identified and corrected an error in the cached membership of a dynamic group: 10AEE3CE-FE3D-4FF8-81FD-483B044F3752.

 

Correction:  Removal

Member: 9153AC48-9AAE-48FE-AF52-51C180ADDCBF".

 

Weird Behavior 1

Every night, exactly the same execution occurs (i.e. same sets and groups corrected with the same members removal) in the Event  Viewer! The job seems to be unable to remove the users from this so called "cache". This is contradictory with the event IDs logged.

 

Weird Behavior 2 (probably linked to #1)

If I log-in to the portal and check one set ("View Members" button) the so-called corrected member is not listed as a member. That set is typically used in a transition-in MPR that determines the user status (active/inactive). In our case the user is never de-activated.

If I change manually the attributes that determines the set membership (en date in the future and then back in the past), the user end-up being deactivated.

If I re-run the SetTemporalJob again, the same event id occurs and the user ends being reactivated.

 

Q1 : What's this "membership cache" ?

Q2 : Any idea regarding how to fix this annoying behavior ?

 

Thanks in advance for your help,

Sylvain

Edit (product version) : FIM 2010 R2 SP1 (build 4.1.3441.0)

• Edited by Sylvain_Castillon Friday, November 22, 2013 2:31 PM added product version

I'm not offering an answer, but in my experience this tends to point to a problem with either the filter definition or with index fragmentation of selected FIMService database tables.  Check for evidence of the error in the above link.

Same issue for a temporal SET on this version (but with event ID 33).

I updated to last build (4.1.3496.0) but the issue is not corrected.

I found it on SCOM MP for FIM documentation. So, SQL Job corrects membership but not entitlement. Manual action has to be done in order to check and correct entitlement.

FIM Service Set Corrections

The FIM Service periodically checks whether its set memberships are correct. If these memberships are incorrect, then users may have the wrong policy applied to them.

This monitor changes state when the FIM Service discovers that a set membership was incorrect and users may be out of policy. An example of being out of policy is in a rare condition when a user may get provisioned an entitlement he or she would not otherwise have access to because of an incorrect set evaluation. The FIM Service corrects the set membership, but does not correct the entitlement. It is necessary for a FIM expert to audit the users entitlements to ensure that they match the desired policy.

Because this monitor requires a FIM expert to investigate, the monitor is implemented as a manual reset monitor. We recommend enabling this monitor only if you have a process in place to investigate and resolve this monitor manually. Our experience shows most customer environments never encounter this situation and that this monitor may be safely disabled. Other mechanisms including auditing reports can help protect against undue entitlements.

Target: FIM Service

ID	Microsoft.Forefront.IdentityManager.2010.Service.Monitor.ServiceVerifiesSetMembership
Name	Set Membership Cache is Correct
Trace source	Microsoft.ResourceManagement.ServiceHealthSource
Event ID	33
Occurs	When the FIM Service identifies an incorrect set membership, this monitor changes state.

This WIKI article may assist further understanding.

I found it on SCOM MP for FIM documentation. So, SQL Job corrects membership but not entitlement. Manual action has to be done in order to check and correct entitlement.

FIM Service Set Corrections

The FIM Service periodically checks whether its set memberships are correct. If these memberships are incorrect, then users may have the wrong policy applied to them.

This monitor changes state when the FIM Service discovers that a set membership was incorrect and users may be out of policy. An example of being out of policy is in a rare condition when a user may get provisioned an entitlement he or she would not otherwise have access to because of an incorrect set evaluation. The FIM Service corrects the set membership, but does not correct the entitlement. It is necessary for a FIM expert to audit the users entitlements to ensure that they match the desired policy.

Because this monitor requires a FIM expert to investigate, the monitor is implemented as a manual reset monitor. We recommend enabling this monitor only if you have a process in place to investigate and resolve this monitor manually. Our experience shows most customer environments never encounter this situation and that this monitor may be safely disabled. Other mechanisms including auditing reports can help protect against undue entitlements.

Target: FIM Service

ID	Microsoft.Forefront.IdentityManager.2010.Service.Monitor.ServiceVerifiesSetMembership
Name	Set Membership Cache is Correct
Trace source	Microsoft.ResourceManagement.ServiceHealthSource
Event ID	33
Occurs	When the FIM Service identifies an incorrect set membership, this monitor changes state.

• Proposed as answer by UNIFYBobMVP 22 hours 39 minutes ago

I found it on SCOM MP for FIM documentation. So, SQL Job corrects membership but not entitlement. Manual action has to be done in order to check and correct entitlement.

FIM Service Set Corrections

The FIM Service periodically checks whether its set memberships are correct. If these memberships are incorrect, then users may have the wrong policy applied to them.

This monitor changes state when the FIM Service discovers that a set membership was incorrect and users may be out of policy. An example of being out of policy is in a rare condition when a user may get provisioned an entitlement he or she would not otherwise have access to because of an incorrect set evaluation. The FIM Service corrects the set membership, but does not correct the entitlement. It is necessary for a FIM expert to audit the users entitlements to ensure that they match the desired policy.

Because this monitor requires a FIM expert to investigate, the monitor is implemented as a manual reset monitor. We recommend enabling this monitor only if you have a process in place to investigate and resolve this monitor manually. Our experience shows most customer environments never encounter this situation and that this monitor may be safely disabled. Other mechanisms including auditing reports can help protect against undue entitlements.

Target: FIM Service

ID	Microsoft.Forefront.IdentityManager.2010.Service.Monitor.ServiceVerifiesSetMembership
Name	Set Membership Cache is Correct
Trace source	Microsoft.ResourceManagement.ServiceHealthSource
Event ID	33
Occurs	When the FIM Service identifies an incorrect set membership, this monitor changes state.

• Proposed as answer by UNIFYBobMVP Tuesday, November 26, 2013 1:09 PM

Thanks for your replies.

If I may add something, my guess is that when the FIM_TemporalEventsJob triggers too many membership updates you might encounter some "cached object removal/add" errors (Health ID 33/34).

As a matter of fact, having too many Set correction should definitely be a thing to avoid and the Wiki article (Markus), your blog entry and this blog entry (Carol) explains very well the basics on how to prevent some design flaws, identify performance issues and monitor these events.

• That was our case : we had too many dynamic groups with temporal filter defined; they were automatically generated based on some objects lifecycle.
• After redesigning these group filters, deleting the old ones and generating the new ones, the FIM_TemporalEventsJob didn't triggered any new event ID 34.

If I'm correct about the fact that what really explains this issue is the amount of membership update requests generated; you could probably encounter this error with a very simple filter definition after just batch updating users' attribute linked to this filter. Then, you would probably have to manually correct the associated errors with some workaround.

• Redefine the XPath filter and exclude the users' Resource ID referenced in the events ID 34.
• Save the Set.
• Put back the original XPath filter.

I'm still wondering whether the difference between ID 33/34 is linked to a "Set/Group" or to "Temporal/Not Temporal" concept though

• Edited by Sylvain_Castillon 46 minutes ago

Thanks for your replies.

If I may add something, my guess is that when the FIM_TemporalEventsJob triggers too many membership updates you might encounter some "cached object removal/add" errors (Health ID 33/34).

As a matter of fact, having too many Set correction should definitely be a thing to avoid and the Wiki article (Markus), your blog entry and this blog entry (Carol) explains very well the basics on how to prevent some design flaws, identify performance issues and monitor these events.

• That was our case : we had too many dynamic groups with temporal filter defined; they were automatically generated based on some objects lifecycle.
• After redesigning these group filters, deleting the old ones and generating the new ones, the FIM_TemporalEventsJob didn't triggered any new event ID 34.

If I'm correct about the fact that what really explains this issue is the amount of membership update requests generated; you could probably encounter this error with a very simple filter definition after just batch updating users' attribute linked to this filter. Then, you would probably have to manually correct the associated errors with some workaround.

• Redefine the XPath filter and exclude the users' Resource ID referenced in the events ID 34.
• Save the Set.
• Put back the original XPath filter.

I'm still wondering whether the difference between ID 33/34 is linked to a "Set/Group" or to "Temporal/Not Temporal" concept though

• Edited by Sylvain_Castillon Wednesday, December 11, 2013 11:07 AM